There is probably somewhat of an open question as to whether we want to add a new dependency to support fp16 encoding or not. It is certainly a bit of a shame that all consumers would need to take on the dependency, even if they do not end up using the HNSW index.

I could see the argument that we need yet another subproject here for vector indexes, and that's where we put the new code, like was done with fdb-record-layer-lucene. Then projects that don't use the new vector sub-component don't need to worry about this.

I did also take a quick look, and it actually seems like writing our own fp32 to fp16 utility wouldn't be that hard. In the common case, it's just a matter of truncating the mantissa and re-encoding the exponent. There are some truncation edge cases (e.g., the numbers can blow up to infinity for a lot of exponent values) that aren't that bad, and then the only "hard" case is making sure that you can convert from a normal 32 (or 64) bit value to a sub-normal 16-bit value. But even that isn't too bad. I have some prototype code locally that could theoretically do that, using java short values as the storage for 16-bit values. Getting the logic to go back and forth is actually not too bad; if we actually want to be able to do fp16 math on those shorts, that's a little more intense, though actually maybe not too too bad if we absolutely needed to.

Any reason for this? Should we revert it?

Is there a reason the base Vector class wraps a double vector? Rather than, say, a FloatVector wrapping a float[]?

minor: Should this be dimension rather than size? I don't think I actually have an opinion here, but it occurs to me as a decision we could make

It may be the answer is "no", but is there a better name than vector? The main concern is that it conflicts with the abstract data type name. But it also appears to be the name that other systems use for this. The only alternative name I could think of would be something like FloatingPointVector or like CartesianVector or something, neither of which I'm all that happy with

Two things:

1. Should this reference the Metric objects from the Metrics enum? It seems weird to have that enum but still create instances of the metric implementations on their own
2. Why is dotProductMetric handled differently from all of the other metrics

Could this be parameterized on the Metric type? I believe all of the metrics should return zero on identical vectors except for dot product. The EnumSource argument provider can be set up to exclude values, which we could do to skip that particular one

This correct distance metric could also be made generic on the different types, though it would require a more involved arguments provider. Probably something like:

static Stream<Arguments> metricAndExpectedDistance() {
    // Distance between (1.0, 2.0) and (4.0, 6.0)
    return Stream.of(
        Arguments.of(Metrics.MANHATTAN, 7.0), // |1 - 4| + |2 - 6| = 7
        Arguments.of(Metrics.EUCLIDEAN, 5.0),  // sqrt((1-4)^2 + (2-6)^2) = sqrt(9 + 16) = 5.0
        Arguments.of(Metrics.SQUARE_EUCLIDEAN, 25.0), // (1-4)^2 + (2-6)^2 = 9 + 16 = 25
        // etc
    );
}

This should also probably add tests of the comparative distance function, to be sure. I could also see us adding a test of the triangle inequality, for the two that support it.

This would probably be a good spot to add a few more unit tests of the Vector class, including things like the hash code and converting between HalfVector and DoubleVector